Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.85%. Comparing base (464b4dc) to head (0bd4d9d).

@@           Coverage Diff           @@
##             main     #363   +/-   ##
=======================================
  Coverage   93.85%   93.85%           
=======================================
  Files          28       28           
  Lines        6165     6165           
=======================================
  Hits         5786     5786           
  Misses        379      379           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This looks great! Thanks for putting this together!

I want to bring this to attention, the maintainers of GDAL are currently discussing restricting AI/LLM usage: OSGeo/gdal#14500

Also worth of checking arguments in gdal-dev list: https://lists.osgeo.org/pipermail/gdal-dev/2026-May/061592.html.

Particular interesting example of AI introducing bloated code, which by reviewing from experienced maintainer wasn't captured:

• JP2Grok: new raster driver for Grok JPEG 2000 toolkit OSGeo/gdal#14204 (PR with AI)
• Optimize CPLHaveRuntimeAVX2() on gcc and Simplify rasterio.cpp wrt AVX2 use OSGeo/gdal#14236 (fix by maintainer)

There is a nice overview of different AI policies over at https://github.com/melissawm/open-source-ai-contribution-policies.

A nice blog post from Stéfan van der Walt covers many aspects of the ongoing discussions https://blog.scientific-python.org/scientific-python/community-considerations-around-ai/.

A main concern in many of the above is on copyright issues. We do not have anything mentioning copyright or code ownership in the suggested policy. Worth discussing how we should go forward.

This is an interesting and difficult topic which redefines our work. Here are a few comments:

• The AI world is evolving fast. I think it is is difficult to define rules in too much details. I would use a few principles and review it regularly.

• In my experience, the human and the LLM benefit from discussing together the goal and the logic of an issue. The LLM is much more efficient at implementing a solution following standard best practices than the human. Having a human reviewing each line significantly reduces the benefit. Another independent LLM can actually do the review under human control.

• It is important to keep the code concise in order to ensure the quality of the LLM output and reduce its cost (the latest big models are actually quite good at this). Important information that is implicitly used by human programmers in this particular project (e.g. the FM301 standard) should be communicated to the LLM together with repo best practices in an agent.md.

• Should we allow any kind of LLM provider and usage or should we restrict it following some official security guidelines (at least for the review part)? I expect the use of LLM to be consistent with our license.

As mentioned before, GDAL, a cornerstone project in geospatial (MIT license), just adapted their AI policy, restricting AI usage to the minimum.

We should be very careful in adopting AI usage, especially for the following points:

• Copyright Infringement & "Code Laundering"
• Open-Source Licensing Violations (Copyleft)
• Ownership and IP

Can we legally prove that a third party doesn't actually own LLM generated code which is about to be merged into our code base? Is it possible at all to check if LLM generated code is not violating any licenses? Who owns the LLM generated code, if authorship requires human creation?

I created an experimental PR using AI for both implementation and review to help the discussion (#383).

@kmuehlbauer I don't think there is any practical way to enforce copyrights outside of requiring that the human submitting the PR attest thath they have not violated copyright (which anyone can just say "no").

@rcjackson Yes, sure, we are trusting each contributor that the submitted code is of their own origin and/or can be ingested legally. But, given that we know LLM's have been trained on FOSS and any other available code, how can the human submitting the PR attest that anyhow? How should the human know, if the LLM reproduced a copyrighted part of training data? We would be shifting our trust in humans into trusting black boxes.

Who is the author of that particular generated code? Is it the human submitter, or does it belong to the public domain? There are so many unanswered questions with regard to LLM generated code, that I find it at least difficult if not impossible to safely use it.

@kmuehlbauer there is no guarantee that a human-only PR also does not violate copyright standards either. If you are going to apply that standard to any PR. A human can also do the same thing, and often does learn from FOSS software. If you apply your standards, then no PR can ever be trusted, human or AI.

@rcjackson Thanks, that's all valid. And, true, there is no such guarantee. A human contributor may be imperfect, but they are still a legible and accountable source. An LLM is not. If we treat both as equivalent, we are not being consistent, IMHO.

The only escape hatch is to trust the human submitter of LLM generated code as if it would be entirely their own code. Going that path still does not account for any future legal developments.

Yes, maybe I'm too cautious and unsure about it. But, obviously others feel the same if we look how the different AI policies are evolving across projects and organizations. There is still no real consensus on how to properly classify or govern LLM generated contributions. That lack of consensus itself is already a signal that the problem is not settled at all.

I'm with those who converge on caution rather than assuming equivalence between human and LLM generated code.

Would be great to hear more opinions. Should we be more strict or more permissive here? What concrete criteria would make LLM assisted contributions clearly acceptable without weakening our expectations around authorship, accountability, and provenance?